Implementatie van Web Security Headers: JavaScript Content Security Policy (CSP)

In het huidige digitale landschap is webbeveiliging van het grootste belang. Het beschermen van uw website en uw gebruikers tegen kwaadaardige aanvallen is niet langer optioneel, maar een noodzaak. Cross-Site Scripting (XSS) blijft een veelvoorkomende bedreiging, en een van de meest effectieve verdedigingen is het implementeren van een sterk Content Security Policy (CSP). Deze gids richt zich op het gebruik van JavaScript voor het beheren en implementeren van CSP, wat een dynamische en flexibele aanpak biedt om uw webapplicaties wereldwijd te beveiligen.

Wat is Content Security Policy (CSP)?

Content Security Policy (CSP) is een HTTP-responseheader waarmee u kunt bepalen welke bronnen de user agent (browser) mag laden voor een bepaalde pagina. In wezen fungeert het als een whitelist, die de herkomst definieert van waaruit scripts, stylesheets, afbeeldingen, lettertypen en andere bronnen geladen mogen worden. Door deze bronnen expliciet te definiëren, kunt u het aanvalsoppervlak van uw website aanzienlijk verkleinen, waardoor het voor aanvallers veel moeilijker wordt om kwaadaardige code te injecteren en XSS-aanvallen uit te voeren. Het is een belangrijke laag in een diepgaande verdediging.

Waarom JavaScript gebruiken voor CSP-implementatie?

Hoewel CSP direct kan worden geconfigureerd in de configuratie van uw webserver (bijv. Apache's .htaccess of Nginx's config-bestand), biedt het gebruik van JavaScript verschillende voordelen, vooral in complexe of dynamische applicaties:

• Dynamische Beleidsgeneratie: JavaScript stelt u in staat om CSP-beleid dynamisch te genereren op basis van gebruikersrollen, de status van de applicatie of andere runtime-condities. Dit is met name handig in single-page applications (SPA's) of applicaties die sterk afhankelijk zijn van client-side rendering.
• Op Nonce gebaseerde CSP: Het gebruik van nonces (cryptografisch willekeurige, eenmalige tokens) is een zeer effectieve manier om inline scripts en stijlen te beveiligen. JavaScript kan deze nonces genereren en toevoegen aan zowel de CSP-header als de inline script/style-tags.
• Op Hash gebaseerde CSP: Voor statische inline scripts of stijlen kunt u hashes gebruiken om specifieke codefragmenten op een whitelist te plaatsen. JavaScript kan deze hashes berekenen en opnemen in de CSP-header.
• Flexibiliteit en Controle: JavaScript geeft u fijnmazige controle over de CSP-header, waardoor u deze 'on the fly' kunt aanpassen op basis van specifieke applicatiebehoeften.
• Foutopsporing en Rapportage: JavaScript kan worden gebruikt om CSP-schendingsrapporten vast te leggen en naar een centrale logserver te sturen voor analyse, wat u helpt bij het identificeren en oplossen van beveiligingsproblemen.

Uw JavaScript CSP instellen

De algemene aanpak omvat het genereren van een CSP-headerstring in JavaScript en vervolgens het instellen van de juiste HTTP-responseheader aan de server-kant (meestal via uw backend-framework). We zullen specifieke voorbeelden voor verschillende scenario's bekijken.

1. Nonces genereren

Een nonce (number used once) is een willekeurig gegenereerde, unieke waarde die wordt gebruikt om specifieke inline scripts of stijlen op een whitelist te plaatsen. Hier ziet u hoe u een nonce in JavaScript kunt genereren:

            function generateNonce() {
  const crypto = window.crypto || window.msCrypto; // Voor IE-ondersteuning
  if (!crypto || !crypto.getRandomValues) {
    // Fallback voor oudere browsers zonder crypto API
    return Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);
  }
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return btoa(String.fromCharCode.apply(null, new Uint8Array(arr.buffer)));
}

const nonce = generateNonce();
console.log("Generated Nonce:", nonce);

            

              
                Copy
              
            
          

Dit codefragment genereert een cryptografisch veilige nonce met behulp van de ingebouwde crypto API van de browser (indien beschikbaar) en valt terug op een minder veilige methode als de API niet wordt ondersteund. De gegenereerde nonce wordt vervolgens base64-gecodeerd voor gebruik in de CSP-header.

2. Nonces injecteren in inline scripts

Zodra u een nonce heeft, moet u deze injecteren in zowel de CSP-header als de <script>-tag:

HTML:

            <script nonce="YOUR_NONCE_HERE">
  // Uw inline scriptcode hier
  console.log("Hallo vanuit inline script!");
</script>
            

              
                Copy
              
            
          

JavaScript (Backend):

            const nonce = generateNonce();
const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;

// Voorbeeld met Node.js en Express:
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', cspHeader);
  // Geef de nonce door aan de view of template engine
  res.locals.nonce = nonce;
  next();
});

            

              
                Copy
              
            
          

Belangrijke opmerkingen:

• Vervang YOUR_NONCE_HERE in de HTML door de daadwerkelijk gegenereerde nonce. Dit wordt vaak server-side gedaan met behulp van een templating engine. Het bovenstaande voorbeeld illustreert het doorgeven van de nonce aan de templating engine.
• De script-src-directive in de CSP-header bevat nu 'nonce-${nonce}', waardoor scripts met de overeenkomende nonce kunnen worden uitgevoerd.
• 'strict-dynamic' wordt toegevoegd aan de `script-src`-directive. Deze directive vertelt de browser om scripts te vertrouwen die door vertrouwde scripts worden geladen. Als een script-tag een geldige nonce heeft, wordt elk script dat het dynamisch laadt (bijv. met `document.createElement('script')`) ook vertrouwd. Dit vermindert de noodzaak om talloze individuele domeinen en CDN-URL's op een whitelist te plaatsen en vereenvoudigt het CSP-onderhoud aanzienlijk.
• 'unsafe-inline' wordt over het algemeen afgeraden bij het gebruik van nonces omdat het de CSP verzwakt. Het is hier echter opgenomen voor demonstratiedoeleinden en moet in productie worden verwijderd. Verwijder dit zo snel mogelijk.

3. Hashes genereren voor inline scripts

Voor statische inline scripts die zelden veranderen, kunt u hashes gebruiken in plaats van nonces. Een hash is een cryptografische digest van de inhoud van het script. Als de inhoud van het script verandert, verandert de hash ook, en zal de browser het script blokkeren.

De hash berekenen:

U kunt online tools of command-line utilities zoals OpenSSL gebruiken om de SHA256-hash van uw inline script te genereren. Bijvoorbeeld:

            openssl dgst -sha256 -binary your_script.js | openssl base64
            

              
                Copy
              
            
          

Voorbeeld:

Stel dat uw inline script is:

            <script>
  console.log("Hallo vanuit inline script!");
</script>
            

              
                Copy
              
            
          

De SHA256-hash van dit script (zonder de <script>-tags) zou kunnen zijn:

            sha256-YOUR_HASH_HERE
            

              
                Copy
              
            
          

CSP-header:

            const cspHeader = `default-src 'self'; script-src 'self' 'sha256-YOUR_HASH_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
            

              
                Copy
              
            
          

Vervang YOUR_HASH_HERE door de daadwerkelijke SHA256-hash van de inhoud van uw script.

Belangrijke overwegingen voor hashes:

• De hash moet worden berekend op de exacte inhoud van het script, inclusief witruimte. Elke wijziging aan het script, zelfs een enkel teken, maakt de hash ongeldig.
• Hashes zijn het meest geschikt voor statische scripts die zelden veranderen. Voor dynamische scripts zijn nonces een betere optie.

4. De CSP-header instellen op de server

De laatste stap is het instellen van de Content-Security-Policy HTTP-responseheader op uw server. De exacte methode hangt af van uw server-side technologie.

Node.js met Express:

            app.use((req, res, next) => {
  const nonce = generateNonce();
  const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
  res.setHeader('Content-Security-Policy', cspHeader);
  res.locals.nonce = nonce; // Maak nonce beschikbaar voor templates
  next();
});
            

              
                Copy
              
            
          

Python met Flask:

            from flask import Flask, make_response, render_template, g
import os
import base64

app = Flask(__name__)

def generate_nonce():
    return base64.b64encode(os.urandom(16)).decode('utf-8')

@app.before_request
def before_request():
    g.nonce = generate_nonce()

@app.after_request
def after_request(response):
    csp = "default-src 'self'; script-src 'self' 'nonce-{nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests".format(nonce=g.nonce)
    response.headers['Content-Security-Policy'] = csp
    return response

@app.route('/')
def index():
    return render_template('index.html', nonce=g.nonce)

            

              
                Copy
              
            
          

PHP:

            <?php
function generateNonce() {
  return base64_encode(random_bytes(16));
}

$nonce = generateNonce();
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-" . $nonce . "' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests");
?>
<!DOCTYPE html>
<html>
<head>
  <title>CSP Voorbeeld</title>
</head>
<body>
  <script nonce="<?php echo htmlspecialchars($nonce, ENT_QUOTES, 'UTF-8'); ?>">
    console.log("Hallo vanuit inline script!");
  </script>
</body>
</html>
            

              
                Copy
              
            
          

Apache (.htaccess):

Hoewel niet aanbevolen voor dynamische CSP, *kunt* u een statische CSP instellen met .htaccess:

            <IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;"
</IfModule>
            

              
                Copy
              
            
          

Nginx:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;";
            

              
                Copy
              
            
          

Belangrijke opmerkingen:

• Vervang 'self' door het/de daadwerkelijke domein(en) van waaruit u wilt toestaan dat bronnen worden geladen.
• Wees uiterst voorzichtig bij het gebruik van 'unsafe-inline' en 'unsafe-eval'. Deze directives verzwakken de CSP aanzienlijk en moeten waar mogelijk worden vermeden.
• Gebruik upgrade-insecure-requests om alle HTTP-verzoeken automatisch te upgraden naar HTTPS.
• Overweeg het gebruik van report-uri of report-to om een eindpunt te specificeren voor het ontvangen van CSP-schendingsrapporten.

CSP-directives uitgelegd

CSP gebruikt directives om de toegestane bronnen voor verschillende soorten resources te specificeren. Hier is een kort overzicht van enkele van de meest voorkomende directives:

• default-src: Specificeert de standaardbron voor alle resources die niet expliciet door andere directives worden gedekt.
• script-src: Specificeert de toegestane bronnen voor JavaScript.
• style-src: Specificeert de toegestane bronnen voor stylesheets.
• img-src: Specificeert de toegestane bronnen voor afbeeldingen.
• font-src: Specificeert de toegestane bronnen voor lettertypen.
• media-src: Specificeert de toegestane bronnen voor audio en video.
• object-src: Specificeert de toegestane bronnen voor plug-ins (bijv. Flash). Over het algemeen moet u dit instellen op 'none' om plug-ins uit te schakelen.
• frame-src: Specificeert de toegestane bronnen voor frames en iframes.
• connect-src: Specificeert de toegestane bronnen voor XMLHttpRequest, WebSocket en EventSource-verbindingen.
• base-uri: Specificeert de toegestane basis-URI's voor het document.
• form-action: Specificeert de toegestane eindpunten voor het verzenden van formulieren.
• upgrade-insecure-requests: Instrueert de user agent om alle onveilige URL's van een site (die via HTTP worden aangeboden) te behandelen alsof ze zijn vervangen door veilige URL's (die via HTTPS worden aangeboden). Deze directive is bedoeld voor websites die volledig zijn gemigreerd naar HTTPS.
• report-uri: Specificeert een URI waarnaar de browser rapporten van CSP-schendingen moet sturen. Deze directive is verouderd ten gunste van `report-to`.
• report-to: Specificeert een benoemd eindpunt waarnaar de browser rapporten van CSP-schendingen moet sturen.

Trefwoorden voor CSP-bronlijst

Elke directive gebruikt een bronlijst om de toegestane bronnen te specificeren. De bronlijst kan de volgende trefwoorden bevatten:

• 'self': Staat bronnen van dezelfde oorsprong toe (schema, host en poort).
• 'none': Weigert bronnen van elke oorsprong.
• 'unsafe-inline': Staat inline scripts en stijlen toe. Vermijd dit waar mogelijk.
• 'unsafe-eval': Staat het gebruik van eval() en gerelateerde functies toe. Vermijd dit waar mogelijk.
• 'strict-dynamic': Specificeert dat het vertrouwen dat de browser aan een script op de pagina geeft vanwege een bijbehorende nonce of hash, wordt doorgegeven aan de scripts die door dat script worden geladen.
• 'data:': Staat bronnen toe die via het data:-schema worden geladen (bijv. inline afbeeldingen). Gebruik met de nodige voorzichtigheid.
• 'mediastream:': Staat bronnen toe die via het mediastream:-schema worden geladen.
• https:: Staat bronnen toe die via HTTPS worden geladen.
• http:: Staat bronnen toe die via HTTP worden geladen. Over het algemeen afgeraden.
• *: Staat bronnen van elke oorsprong toe. Vermijd dit; het ondermijnt het doel van CSP.

Rapportage van CSP-schendingen

Rapportage van CSP-schendingen is cruciaal voor het monitoren en debuggen van uw CSP. Wanneer een resource de CSP schendt, kan de browser een rapport naar een gespecificeerde URI sturen.

Een rapportage-eindpunt instellen:

U heeft een server-side eindpunt nodig om CSP-schendingsrapporten te ontvangen en te verwerken. Het rapport wordt verzonden als een JSON-payload.

Voorbeeld (Node.js met Express):

            app.post('/csp-report', (req, res) => {
  console.log('CSP-schendingsrapport:', req.body);
  // Verwerk het rapport (bijv. log naar een bestand of database)
  res.status(204).end(); // Antwoord met een 204 No Content status
});
            

              
                Copy
              
            
          

De report-uri of report-to-directive configureren:

Voeg de report-uri of `report-to`-directive toe aan uw CSP-header. `report-uri` is verouderd, dus geef de voorkeur aan `report-to`.

            const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-to csp-endpoint;`;
            

              
                Copy
              
            
          

U moet ook een Reporting API-eindpunt configureren met de `Report-To`-header.

            Report-To: { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [{"url": "/csp-report"}], "include_subdomains": true }
            

              
                Copy
              
            
          

Opmerking:

• De `Report-To`-header moet bij elk verzoek aan uw server worden ingesteld, anders kan de browser de configuratie negeren.
• `report-uri` is minder veilig dan `report-to` omdat het geen TLS-versleuteling van het rapport toestaat, en het is verouderd, dus geef de voorkeur aan `report-to`.

Voorbeeld van een CSP-schendingsrapport (JSON):

            {
  "csp-report": {
    "document-uri": "https://example.com/page.html",
    "referrer": "",
    "violated-directive": "script-src 'self' 'nonce-YOUR_NONCE_HERE'",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; script-src 'self' 'nonce-YOUR_NONCE_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-uri /csp-report;",
    "blocked-uri": "https://evil.com/malicious.js",
    "status-code": 200,
    "script-sample": ""
  }
}
            

              
                Copy
              
            
          

Door deze rapporten te analyseren, kunt u CSP-schendingen identificeren en oplossen, zodat uw website veilig blijft.

Best practices voor CSP-implementatie

• Begin met een restrictief beleid: Begin met een beleid dat alleen bronnen van uw eigen oorsprong toestaat en maak het geleidelijk losser als dat nodig is.
• Gebruik nonces of hashes voor inline scripts en stijlen: Vermijd het gebruik van 'unsafe-inline' waar mogelijk.
• Gebruik 'strict-dynamic' om het CSP-onderhoud te vereenvoudigen.
• Vermijd het gebruik van 'unsafe-eval': Als u eval() moet gebruiken, overweeg dan alternatieve benaderingen.
• Gebruik upgrade-insecure-requests: Upgrade alle HTTP-verzoeken automatisch naar HTTPS.
• Implementeer rapportage van CSP-schendingen: Monitor uw CSP op schendingen en los ze snel op.
• Test uw CSP grondig: Gebruik de ontwikkelaarstools van de browser om eventuele CSP-problemen te identificeren en op te lossen.
• Gebruik een CSP-validator: Online tools kunnen u helpen de syntaxis van uw CSP-header te valideren en mogelijke problemen te identificeren.
• Overweeg het gebruik van een CSP-framework of -bibliotheek: Verschillende frameworks en bibliotheken kunnen u helpen de implementatie en het beheer van CSP te vereenvoudigen.
• Herzie uw CSP regelmatig: Naarmate uw applicatie evolueert, moet uw CSP mogelijk worden bijgewerkt.
• Informeer uw team: Zorg ervoor dat uw ontwikkelaars CSP en het belang ervan begrijpen.
• Implementeer CSP in fasen: Begin met het implementeren van CSP in rapportagemodus (report-only) om schendingen te monitoren zonder bronnen te blokkeren. Zodra u er zeker van bent dat uw beleid correct is, kunt u het in de handhavingsmodus inschakelen.
• Documenteer uw CSP: Houd een administratie bij van uw CSP-beleid en de redenen achter elke directive.
• Houd rekening met browsercompatibiliteit: De ondersteuning voor CSP varieert per browser. Test uw CSP op verschillende browsers om ervoor te zorgen dat het naar verwachting werkt.
• Geef prioriteit aan beveiliging: CSP is een krachtig hulpmiddel voor het verbeteren van de webbeveiliging, maar het is geen wondermiddel. Gebruik het in combinatie met andere best practices voor beveiliging om uw website te beschermen tegen aanvallen.
• Overweeg het gebruik van een Web Application Firewall (WAF): Een WAF kan u helpen CSP-beleid te handhaven en uw website te beschermen tegen andere soorten aanvallen.

Veelvoorkomende uitdagingen bij CSP-implementatie

• Scripts van derden: Het identificeren en op een whitelist plaatsen van alle domeinen die vereist zijn door scripts van derden kan een uitdaging zijn. Gebruik waar mogelijk `strict-dynamic`.
• Inline stijlen en event handlers: Het omzetten van inline stijlen en event handlers naar externe stylesheets en JavaScript-bestanden kan tijdrovend zijn.
• Browsercompatibiliteitsproblemen: De ondersteuning voor CSP varieert per browser. Test uw CSP op verschillende browsers om ervoor te zorgen dat het naar verwachting werkt.
• Onderhoudslast: Het up-to-date houden van uw CSP naarmate uw applicatie evolueert, kan een uitdaging zijn.
• Prestatie-impact: CSP kan een lichte prestatie-overhead introduceren vanwege de noodzaak om bronnen te valideren aan de hand van het beleid.

Wereldwijde overwegingen voor CSP

Houd bij het implementeren van CSP voor een wereldwijd publiek rekening met het volgende:

• CDN-providers: Als u CDN's gebruikt, zorg er dan voor dat u de juiste CDN-domeinen op de whitelist plaatst. Veel CDN's bieden regionale eindpunten; het gebruik hiervan kan de prestaties voor gebruikers op verschillende geografische locaties verbeteren.
• Taalspecifieke bronnen: Als uw website meerdere talen ondersteunt, zorg er dan voor dat u de benodigde bronnen voor elke taal op de whitelist plaatst.
• Regionale regelgeving: Wees u bewust van eventuele regionale regelgeving die van invloed kan zijn op uw CSP-vereisten.
• Toegankelijkheid: Zorg ervoor dat uw CSP niet per ongeluk bronnen blokkeert die nodig zijn voor toegankelijkheidsfuncties.
• Testen in verschillende regio's: Test uw CSP in verschillende geografische regio's om ervoor te zorgen dat het voor alle gebruikers naar verwachting werkt.

Conclusie

Het implementeren van een robuust Content Security Policy (CSP) is een cruciale stap in het beveiligen van uw webapplicaties tegen XSS-aanvallen en andere bedreigingen. Door JavaScript te gebruiken om uw CSP dynamisch te genereren en te beheren, kunt u een hoger niveau van flexibiliteit en controle bereiken, waardoor uw website veilig en beschermd blijft in het steeds veranderende dreigingslandschap van vandaag. Vergeet niet om best practices te volgen, uw CSP grondig te testen en het continu te monitoren op schendingen. Veilig programmeren, een diepgaande verdediging en een goed geïmplementeerde CSP zijn de sleutel tot het bieden van een veilige browse-ervaring voor een wereldwijd publiek.